NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part2/12259

Internet Message Format | 1996-08-05 | 3.2 KB

Path: mail2news.demon.co.uk!genesis.demon.co.uk
From: Lawrence Kirby <[e-mail]>
Newsgroups: comp.lang.c
Subject: Re: Variant Records in C ... Is there a way ?
Date: Sat, 30 Mar 96 00:18:16 GMT
Organization: none
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <4iumf8$[e-mail]> <danpop.827534657@rscernix> <4jcrbm$[e-mail]>
Reply-To: [e-mail]
X-NNTP-Posting-Host: genesis.demon.co.uk
X-Newsreader: Demon Internet Simple News v1.27
X-Mail2News-Path: genesis.demon.co.uk

In article <4jcrbm$[e-mail]>
           [e-mail] "Michael A. Balfour" writes:

>
>In a previous article, [e-mail] (Dan Pop) says:
>
>>In <4iumf8$[e-mail]> [e-mail] (Michael A. Balfour)
> writes:
>>
>>>*However*, if you feel like it, you can still do it yourself with some
>>>clever mallocs and overlaying structures.  Not exactly elegant, but you
>>>can make it pretty memory-efficient.
>>
>>Not exactly blessed by the C standard, either :-)
>>
>
>Maybe not blessed, but it's certainly not condemned.

You'll almost certainly invoke undefined behaviour as far as the language
is concerned. So it is in the same category as void main() or i = i++,
i.e. condemned to be non-portable.

> That's the beauty
>of pointers and typecasting (which my COBOL friends envy).  But I
>suppose you've never had to do anything like this:
>
>int temp=1;
>char *temp2=(char *)&temp;
>#define ByteOrder() ((temp2[0]==0x01) ? LITTLE_ENDIAN : BIG_ENDIAN)

Probably better as:

const int temp = 1;

#define ByteOrder() ((*(unsigned char *)&temp==1) ? LITTLE_ENDIAN : BIG_ENDIAN)

The compiler might even optimise that to a compile time constant.

>Or this:
>
>char buffer[BUF_SIZE];
>int bufEndPtr;
>
>...
>
>void AddIntToBuffer(int num)
>{
>  short i;

It is usually better to use int/unsigned for auxiliary variables - that
is the type that corresponds to the 'natural size suggested by the
archetecture of the execution environment' and is the best bet for
efficiency.

>  for (i=0;i<sizeof(int);i++)  buffer[bufEndPtr++]=((char *)(&num))[i];
>}

You're safer working with unsigned char arrays.

>void AddStringToBuffer(char *s,int len)
>{
>  short i;
>  for (i=0;i<len;i++)  buffer[bufEndPtr++]=s[i];
>}

The language does give license to access any object through character
lvalues. It has been suggested that future revisions of the standard will
clarify the issue so that, say copying an object as an array of unsigned char
works (as long as you end up with suitable alignment). Anyway this is a better
approach than using unions.

>But there are plenty of cases where you might need to go walking through
>a patch of memory that contains data all packed together.  So like I
>said originally, it might not be the most elegant solution, but it can
>certainly be made functional.  And you can write it in ANSI C.

That doesn't mean that ANSI C will guarantee that your code does what
you expect.

--
-----------------------------------------
Lawrence Kirby | [e-mail]
Wilts, England | [e-mail]
-----------------------------------------